-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
connectivity: extend node to node encryption tests #1870
connectivity: extend node to node encryption tests #1870
Conversation
Commits 7c5c9d4, 05a5030, 7c7653d, 3e0b341 do not contain "Signed-off-by". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
3e0b341
to
58b7b18
Compare
I'm already working on the follow-up PR to this (porting the pod-to-pod-strict-mode test to the cilium-cli). Since the future changes are based on this PR, could someone maybe take a look. Maybe @brb? |
Commit e9833c2 does not contain "Signed-off-by". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
e9833c2
to
b4bfd7b
Compare
Commit e9833c2 does not contain "Signed-off-by". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
b4bfd7b
to
7ed9b37
Compare
I rebased the PR to main to fix the CI. btw: the follow-up code implementing the strict mode pod-to-pod test is already finished. I'll create a PR once this is merged, as I depend on this PR. |
Are there any updates regarding the timeline of the review? |
@3u13r Sorry, a bit swamped. I will try to review in 1-2 weeks. |
No worries, just want to make sure that this PR isn't forgotten. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I did a quick skim of the PR. I will do the review once the commit msgs have been extended.
The default value is not necessarily reflected in the ConfigMap. Therefore, we need to set the right values when the keys are not found. Accoding to the documented defaults in Cilium's deployment, tunneling with vxlan is enabled if not specified otherwise. Signed-off-by: Leonard Cohnen <[email protected]>
Signed-off-by: Leonard Cohnen <[email protected]>
When tunneling is enabled, and the feature is correctly picked up the the cilium-cli, the encryption test always listens on the tunneling interface for leaked packets. This is wrong as e.g. node-to-node communication is not encapsulated and therefore does not pass the cilium_vxlan interface. Signed-off-by: Leonard Cohnen <[email protected]>
Signed-off-by: Leonard Cohnen <[email protected]>
7ed9b37
to
9e40129
Compare
I extended both commit messages. I assume that the other two commits are small enough to be explained by only the commit message. If not, I'm happy to extend those also. |
Thanks! HOWTO test it against Cilium (we should put it into the contrib docs):
|
Done. Not 100% how to interpret the test failure but I assume that it is unrelated. On the other hand, I couldn't find a recent similar failure. |
Thanks. The ci-e2e has passed (https://github.com/cilium/cilium/actions/runs/5880176520). The rest is irrelevant. |
ci-ipsec-e2e also looks good: https://github.com/cilium/cilium/actions/runs/5889185248 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Unrelated to your PR, but the encryption leak test is a bit brittle, as it depends on the src and netdev derivations, which might become wrong, thus giving a false negative.
To eliminate the src detection, we could use a unique server port, and use it in the tcpdump filter.
However, improving/eliminating the netdev detection is not that trivial.
Thanks for the review and the pointers for testing it against cilium! I can have a look at making this test less brittle. What I always do locally is to disable the encryption and check that the test fails. Since the tests are run in the ci, inverting the test when encryption is disabled is technically an option. But I'll look at the simpler options first. |
This PR extends the node-to-node encryption tests. Before no actions would fail when running them with encryption disabled (Before cilium/cilium#26712 it was 1/3, because the tunneling feature wasn't correctly detected) in one of my environments (WireGuard, tunnel, vxlan, endpointRoutes). I've adapted them so they work with native routing and tunneling with WireGuard (as far as I could test it), i.e. all actions fail when encryption is disabled and succeed if it is enabled.
The first two commits are just some minor cleanup and documentation in the feature detection. Feedback regarding the detection preference comment is especially welcome.
Output before:
Output after: